Hmm, after thinking about this a bit more, this is maybe a bit more philosophically complicated - it comes down to what are these indicators actually used for?

It sounds like your interpretation is: these are the buckets that currently have threads working on them. This is a straightforward definition, but I'm not sure if users actually care about it.

To me, the useful thing to know is: is this bucket stale, or is it up to date. From that point of view, we've tagged the bucket as out of date because we've started processing it, and it's still out of date. I'm not sure it's wrong from a user point of view to leave it tagged - the abandoned bucket is going to take a long time to finish processing, because there is no current thread assigned to it, but from a user point of view - we've started processing it, and we haven't finished processing it yet.

I suppose if you actually thought this was a reasonable way of approaching it, we would just flag all tiles as out of date as soon as an update occured, so you probably will want to use the try/catch approach.

What I realized when thinking about that approach from my point of view though, is that to me, the most important thing to communicate through this UI is "this bucket is an up-to-date, accurate representation of the current state of the upstream network". And currently our indicator for that is "At the moment you see the indicator disappear, that is true". We would be removing that association ... which maybe is worth thinking about?

The intention behind the indicators is definitely to show which tiles are being worked on, hence m_active. I believe we should fix the implementation of this using the exception handler we discussed.

The "how do I know which tiles are stale?" question is a reasonable one, but a separate topic. I'm not aware of other compositors or renderers trying to do more than highlight the active regions, and personally I struggle to see an approach that doesn't result in a lot of visual noise. The current active indicators and tile order give a pretty good indication of where the "high water mark" of up-to-dateness. Note that the implementation goes out of its way not to flash the indicators when updates are very fast, which I think is an indication of a general aversion to additional visual noise amongst our users.

Updated under protest - I increasingly feel that thread assignment is not the useful information to communicate about the state of the image, but based on variable names rather than what's useful, then this is certainly more accurate.

Actually, that's stating my case too strongly - by far the most common case is that the image updates fast enough that you don't really need to think about which tiles have been updated. It's only in extremely slow cases where you would need to actually think about whether tiles are up to date - I'm only thinking about it because this last fix only applies in those extremely slow cases, and I do still feel like it potentially makes things less clear in the only cases where it's a noticeable change.

Anyway, you should take a look at the code - I wasn't completely sure how to square the easiest place to put a completely reliable catch with m_active being private.

Closing in favour of #5348.